解密最受欢迎的开源 Serverless 框架:流量篇
The following article is from 阿里云云原生 Author 元毅
Knative 是一款基于 Kubernetes 的开源 Serverless 应用编排框架,其目标是制定云原生、跨平台的 Serverless 应用编排标准。Knative 主要功能包括基于请求的自动弹性、缩容到 0、多版本管理、基于流量的灰度发布、函数部署以及事件驱动等。
流量管理
Cloud Native
如何做蓝绿发布
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: example-service
namespace: default
spec:
...
traffic:
- percent: 0
revisionName: example-service-1
tag: staging
- percent: 40
revisionName: example-service-2
- percent: 60
revisionName: example-service-3
不同的 revision 版本之间只需要配置对应的流量比例,即可进行流量的蓝绿发布。而回滚到原版本的操作亦是如此,只需要将新版本的流量切回到 0,原版本设置为 100 即可。
指定 tag 进行版本验证
Revision 版本的 GC 策略
retain-since-create-time:表示 revision 从创建时间开始多长时间保留,默认是 48 小时。 retain-since-last-active-time:表示从最后一次活跃状态(表示被 route 引用,即使 traffic 配置为 0,只要被引用也就表示活跃)开始多长时间保留,默认是 15 小时。 min-non-active-revisions:最少非活跃的版本数,默认是 20 个版本数。 max-non-active-revisions:最大非活跃的版本数,默认是 1000 版本数。
apiVersion: v1
kind: ConfigMap
metadata:
name: config-gc
namespace: knative-serving
labels:
app.kubernetes.io/name: knative-serving
app.kubernetes.io/component: controller
app.kubernetes.io/version: "1.8.2"
data:
_example: |
# ---------------------------------------
# Garbage Collector Settings
# ---------------------------------------
# Duration since creation before considering a revision for GC or "disabled".
retain-since-create-time: "48h"
# Duration since active before considering a revision for GC or "disabled".
retain-since-last-active-time: "15h"
# Minimum number of non-active revisions to retain.
min-non-active-revisions: "20"
# Maximum number of non-active revisions to retain
# or "disabled" to disable any maximum limit.
max-non-active-revisions: "1000"
例如,如果要配置立即回收 inactive revision,可以这样配置:
min-non-active-revisions: "0"
max-non-active-revisions: "0"
retain-since-create-time: "disabled"
retain-since-last-active-time: "disabled"
例如,如果要配置只保留 10 个 inactive revision,可以这样配置:
retain-since-create-time: "disabled"
retain-since-last-active-time: "disabled"
max-non-active-revisions: "10"
流量访问
Cloud Native
多网关支持
ALB
apiVersion: v1
kind: ConfigMap
metadata:
name: config-network
namespace: knative-serving
labels:
app.kubernetes.io/name: knative-serving
app.kubernetes.io/component: networking
app.kubernetes.io/version: "1.8.2"
data:
ingress.class: "alb.ingress.networking.knative.dev"
...
微服务网关 MSE
apiVersion: v1
kind: ConfigMap
metadata:
name: config-network
namespace: knative-serving
labels:
app.kubernetes.io/name: knative-serving
app.kubernetes.io/component: networking
app.kubernetes.io/version: "1.8.2"
data:
ingress.class: "mse.ingress.networking.knative.dev"
...
服务网格 ASM(Istio)
apiVersion: v1
kind: ConfigMap
metadata:
name: config-network
namespace: knative-serving
labels:
app.kubernetes.io/name: knative-serving
app.kubernetes.io/component: networking
app.kubernetes.io/version: "1.8.2"
data:
ingress.class: "istio.ingress.networking.knative.dev"
...
Kourier
apiVersion: v1
kind: ConfigMap
metadata:
name: config-network
namespace: knative-serving
labels:
app.kubernetes.io/name: knative-serving
app.kubernetes.io/component: networking
app.kubernetes.io/version: "1.8.2"
data:
ingress.class: "kourier.ingress.networking.knative.dev"
...
上述网关总的来说,ALB 专注与应用负载均衡,云原生网关 MSE 专注于微服务场景,而 ASM 提供了服务网格(Istio)的能力,用户可以结合自身的业务场景选择相应的云产品网关产品,当然如果用户仅需基础的网关能力,也可以选择 Kourier。
多协议支持
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: helloworld-grpc
spec:
template:
metadata:
annotations:
autoscaling.knative.dev/class: kpa.autoscaling.knative.dev
spec:
containers:
- image: docker.io/moul/grpcbin # 该镜像是一个用于测试gRPC的工具,它通过提供gRPC服务来响应请求。
env:
- name: TARGET
value: "Knative"
ports:
- containerPort: 9000
name: h2c
protocol: TCP
gRPC 服务在 Knative 服务中 port 字段下的 name 设置为 h2c。
此外,为了满足单个服务同时暴露 HTTP 和 gRPC 的诉求,我们也扩展了 Knative 能力,支持同时配置 HTTP 和 gRPC 服务暴露,配置示例如下:
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: helloworld-grpc
annotations:
knative.alibabacloud.com/grpc: grpcbin.GRPCBin
spec:
template:
metadata:
annotations:
autoscaling.knative.dev/class: kpa.autoscaling.knative.dev
spec:
containers:
- image: docker.io/moul/grpcbin
args:
- '--production=true'
env:
- name: TARGET
value: "Knative"
ports:
- containerPort: 80
name: http1
protocol: TCP
- containerPort: 9000
name: h2c
protocol: TCP
自定义域名
为单独服务自定义域名
apiVersion: serving.knative.dev/v1alpha1
kind: DomainMapping
metadata:
name: <domain-name>
namespace: <namespace>
spec:
ref:
name: <service-name>
kind: Service
apiVersion: serving.knative.dev/v1
tls:
secretName: <cert-secret>
<domain-name> 设置服务域名 <namespace> 设置命名空间,与服务所在的命名空间一致 <service-name> 目标服务名称 <cert-secret>(可选)证书 secret 名称
自定义全局域名后缀
apiVersion: v1
kind: ConfigMap
metadata:
name: config-domain
namespace: knative-serving
data:
mydomain.com: ""
自定义 Path
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: coffee-mydomain
annotations:
knative.aliyun.com/serving-ingress: cafe.mydomain.com/coffee
spec:
template:
metadata:
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:160e4dc8
流量弹性
Cloud Native
Knative 提供基于流量请求的自动扩缩容 KPA(Knative Pod Autoscaler)能力。实现原理是:Knative Serving 会为每个 Pod 注入一个名为 queue-proxy 的 QUEUE 代理容器,该容器负责向 Autoscaler 报告业务容器的并发指标。Autoscaler 接收到这些指标之后,会根据并发请求数及相应的算法,调整 Deployment 的 Pod 数量,从而实现自动扩缩容。
流量监控
Cloud Native
• 8012:queue-proxy 代理的 http 端口,流量的入口都会到 8012
• 8013:http2 端口,用于 grpc 流量的转发
• 8022:queue-proxy 管理端口,如健康检查
• 9090: queue-proxy 的监控端口,暴露指标供 autoscaler 采集,用于 kpa 扩缩容
• 9091:prometheus 应用监控指标(请求数,响应时长等)
• USER_PORT,是用户配置的容器端口,即业务实际暴露的服务端口,在 ksvc container port 配置的
此外 Knative 提供了 grafana 大盘:https://github.com/knative-extensions/monitoring/tree/main/grafana
大盘数据的纵轴 ops/sec 表示每秒处理请求数。
Response Time:可以查看 Knative 的响应延迟数据,包括 P50、P90、P95 和 P99。
Resource Usages:可以查看 Knative 的资源使用量情况,包括 CPU 和内存。
小结
Cloud Native
本文介绍了 Knative 流量管理、流量访问、基于流量的弹性以及监控,并且我们提供了丰富的云产品网关能力,适用于不同的业务场景。可以看到基于 Knative,可以轻松做到基于流量的按需使用、自动弹性的 Severless 能力。
参考阅读:
本文由高可用架构转载。技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿